This would have caught the accidental changes to the git submodules in
commit 3a0551e ("Dockerfile: bump ESP-ADF to support WIS auth"). As
we've been aiming for no warnings, let's just turn all warnings into
errors.

We will add another HTTP event callback for the ESP Audio HTTP stream,
to avoid adding too much conditionals in the callback used by the audio
pipeline to WIS. Let's rename the current callback function to make it
more clear it is used by the HTTP stream to the API, similar to the
function initializing the HTTP stream (init_ap_to_api).

ESP-IDF's http_parser component will detect the username and password in
the URL, and esp_http_client will set the Authorization header if the
auth type is set to basic, and the parser found a username and password
in the URL. If the parser didn't find a username and password,
esp_http_client will just skip setting the header entirely, so having
auth type hardcoded to basic is not a problem even if users configure a
URL without username and password.

And enable HTTP Basic Auth unconditionally like we do in commit
667e073feb8d ("audio: enable HTTP Basic Auth in HTTP stream to WIS").

Reduce default HTTP stream timeout from 30s to 2s. Letting a user wait
longer for a failure on a voice command or TTS response is terrible UX.

With the existing callbacks for the HTTP streams we can only capture
HTTP response codes. If a problem occurs on a lower layer, this doesn't
trigger these callbacks. Add an extra callback for the HTTP stream audio
element, and use an enum to distinguish which audio element sent the
callback.

When an error occurs, play the error tone from SPIFFS, write an error
message on the display, and on the console.

Using portMAX_DELAY, esp_websocket_client_close might wait forever on
STOPPED_BIT and we never reach the end of was_deinit_task. Instead, wait
for 5 seconds.

If esp_websocket_client_close receives STOPPED_BIT within the timeout,
it returns ESP_OK. If it doesn't receive STOPPED_BIT within the timeout,
it will do the same as esp_websocket_client_stop but also return ESP_OK.
Therefore, call esp_websocket_client_stop after
esp_websocket_client_close to make sure we actually stop the client.

We currently use the default (WEBSOCKET_RECONNECT_TIMEOUT_MS), which is
not guaranteed to always be 10000.

This is in preparation of reworking the reconnect logic when the client
is not connected at the time of sending a message.

In commit 985375c ("was: drop esp_websocket_client_destroy()")
we've dropped esp_websocket_client_destroy() in was_deinit_task(), as it
appeared to cause crashes.

We're still seeing crashes in the WebSocket client, so let's drop the
use of esp_websocket_client_destroy() completely. Instead, if the WAS
WebSocket client appears to be not connected, wait
WAS_RECONNECT_TIMEOUT_MS for it to reconnect, and if after that it's
still not connected, inform the user.

We already explicitly handle HTTP 401 and 406 from WIS, but we don't
print anything to the screen when we hit e.g. a 403 or 404. Handle these
with a generic message printed to the screen, so the user has some
indication about what is going on. Also trigger the configured audio
response.

On STT error, the pipeline would stop after printing "STT error", and
the line would be overwritten with "Thinking".